Communication networks are often bandwidth-limited. Thus, data sent from a sender to a receiver in a given communication network may experience delay (or may even be lost) as a link between the sender and receiver reaches its maximum throughput capability. This is true for Local Area Networks (LANs), the public Internet, cloud computing/storage networks, and the like. For instance, in a network storage environment, the data sent over a network link to a storage device at a data center or data sent over a network link from a storage device to a host is subject to maximum throughput limits and may experience deleterious effects as maximum throughput is reached. Heavy use of a network that may lead to delay and packet loss may be referred to in this example as network congestion.
Some conventional solutions provide for congestion signaling, wherein a receiver that is made aware of congestion in the network (either by detecting congestion itself or being informed of the congestion by a network device) sends feedback to the sender to make the sender aware of the network congestion. When the sender receives the feedback that indicates congestion, the sender may, e.g., reduce its sending bit rate to alleviate the congestion in the network. In many deployed systems, a single sender may have simultaneous sessions with a multitude of receivers, and the sender may adjust a bit rate for some, all, or none of the sessions as appropriate. However, some less honest users of the network may program a receiver not to report congestion, thereby reducing the probability that a sender will adjust a bit rate of a session with that receiver. Such dishonest action may increase the burden on the other receivers to alleviate the network congestion. The following discussion provides examples of conventional attempts to provide accurate congestion feedback as well as to provide a check for honesty of a receiver.
Explicit Congestion Notification (ECN) is defined in the Internet Engineering Task Force (IETF) standard given in Request For Comments (RFC)3186 (where “RFC” is an indication used by some standards bodies identifying a document that describes a technical standard). Two bits, defining four code points, are placed in an Internet Protocol (IP) header. Code point 00 indicates that a device is not ECN capable; 01 and 10 both indicate that a device is ECN capable; and 11 is an indication that congestion is being experienced.
For instance, if a router in a network experiences congestion, the router may insert a 11 into an IP header in a packet destined for a receiver. The receiver detects the congestion indication and sends a feedback packet (e.g., a Transmission Control Protocol (TCP) packet) further indicating the congestion. RFC3186 defines a “ECE” flag in the TCP transport header, and the receiver may use the flag to indicate the congestion state in the network. Upon receipt of the feedback message, the sender may take some action to alleviate the congestion, such as by reducing a bit rate. The sender may also set a Congestion Window Reduced (CWR) flag in an IP packet to indicate to the receiver to stop marking the congestion flag in the feedback packets. Conventional ECN provides only a single value for congestion, limiting its information value.
ECN Nonce (RFC3540) was proposed as an enhancement to conventional ECN. ECN Nonce includes the concept of receiver honesty to prevent a scenario wherein a receiver deliberately suppresses congestion feedback in order to gain higher bandwidth over other sessions in the network. In ECN Nonce, the sender sends a signal “ECT1” to increase a counter at the receiver side. The receiver constantly announces the current value of this counter using the one-bit NS flag in the TCP transport header. The sender checks if the counter value (NS bit) plus the ECE bit in the TCP transport header are same or higher than the count of the sent ECT1 code points. If the received counter is less than the expected value, either the path or the receiver is misbehaving (e.g., not properly supporting ECN or deliberately suppressing congestion feedback to the sender). Otherwise, it is assumed that the path and the receiver are supporting ECN Nonce. It is worth noting that after the receiver receives a congestion indication or after a message loss, the receiver can not know the correct value of the Nonce sum. If this event is not concealed by the receiver, the sender synchronizes to the receiver value. Otherwise, the sender may reset the session.
In another proposed enhancement, called Data Center TCP (DCTCP) by Microsoft Corporation, a congestion code point change in the IP header causes the receiver to immediately trigger an ACK to feedback congestion information. The proposal is compatible with ECN Nonce and does away with the CWR flag. Some drawbacks of DCTCP include that lost ACKs result in loss of congestion information and also that the system may trigger an ACK for every data segment. Another proposal from M. Kuhlewind builds upon DCTCP to use the CWR flag as a shift bit for the last congestion state to protect against a single ACK loss. However, two or more lost ACKs may cause loss of congestion information.
Another proposal called re-ECN by British Telecom uses three bits (NS, CWR, ECE) in the TCP transport header as single field (ECI). ECI is used to signal the current value of the receiver side congestion counter. Such proposal protects against at least two consecutive ACK losses (since it uses three bits), and it provides a higher level of detail about a congestion level of the network. However, such proposal is incompatible with ECN Nonce because it uses all three bits (NS, CWR, ECE) for congestion indication, leaving none for honesty accounting. Thus, a sender cannot tell an honest receiver from a dishonest receiver as with the ECN Nonce technique. There is currently no solution available that provides a higher level of detail about a level of congestion while also being compatible with ECN Nonce or other honesty accounting information.